Controller area network (CAN) is a serial communications protocol which was originally designed for use in automotive applications, but which has now been adopted in a wide variety of other fields including heating, ventilation and air conditioning (HVAC) control systems, process control systems and medical equipment. CAN mainly concerns the requirements of physical and data link layers and has been declared an international standard, namely ISO 11898.
CAN is a message-based, asynchronous, multi-master, broadcast communication system. A CAN network comprises two or more nodes connected to a CAN bus line which is typically provided by a twisted pair of wires. Any node connected to a CAN bus is free to try to transmit a message to other nodes when the CAN bus is free. Each message is assigned a unique identifier which is used to identify the content of the message and to prioritise and filter messages. If two or more nodes start transmitting messages at the same time, then bus access conflict is resolved through a process of arbitration using the identifier and bit-wise comparison of CAN bus states, namely “dominant” and “recessive” levels corresponding to logical ‘0’ and ‘1’ states respectively. When two nodes try to transmit dominant and recessive bits at the same, the dominant bit takes precedence and the dominant value (i.e. ‘0’) appears on the CAN bus. Nodes monitor the CAN bus and so when a node tries to transmit a recessive bit and the CAN bus adopts a dominant value, then the node is able to identify a collision and interrupt transmission, leaving the node that transmitted the dominant bit to continue transmission on the CAN bus.
CAN specifies two frame formats, namely a standard or base frame format (which is compatible with part A or B of the CAN 2.0 protocol) and an extended frame format (which is compatible with part B of the CAN 2.0 protocol). A frame arranged in the standard or base frame format has an 11-bit identifier, whereas a frame arranged in the extended frame format has a two-part identifier made up of an 11-bit base identifier and an 18-bit extension.
CAN specifies four types of frame, namely a data frame for carrying data, a remote frame for requesting transmission of a data frame, an error frame for reporting detection of an error and an overload frame for providing a delay between frames.
Further details of CAN and CAN frame formats can be found in the CAN Specification, version 2.0 (1991) and ISO 11898-1.
CAN buses can transmit data at bit rates of up to 1 Mbit/s and data frames can carry a payload of up to 8 bytes. However, to support higher data rates and larger payloads, a new protocol, CAN with Flexible Data Rate (CAN FD), has been proposed as set out in CAN with Flexible Data-Rate, Specification, version 1.0 (2012).
FIG. 1 shows a CAN FD data frame.
Referring to FIG. 1, a CAN FD data frame is separated from a preceding frame (not shown) by an interframe space (IFS) and is followed by another interframe space or an overload frame.
The CAN FD data frame includes a start of frame (SOF) field, an arbitration field, a control field, a data field, a cyclical redundancy code (CRC) field, an acknowledge (ACK) field and an end of frame (EOF) field.
In a so-called “arbitration phase”, IFS preceding a CAN FD frame and a first portion of the CAN FD frame is transmitted at a standard bit rate (i.e. a CAN bit rate, e.g. 500 kbits−1). In a so-called “data phase”, a second portion of the CAN FD frame can be transmitted at either a standard bit rate or a high bit rate (for example, up to 8 times the CAN bit rate). In another arbitration phase, a third portion of the CAN FD data frame and IFS or overload frame following the CAN FD data frame is transmitted at a standard bit rate.
CAN FD specifies four frame formats, namely CAN standard and CAN extended formats (corresponding to the standard and extended formats specified in ISO 11898-1), CAN FD standard and CAN FD extended formats.
FIG. 2 shows a CAN FD data frame in CAN FD standard (or “base”) format.
Referring to FIG. 2, the arbitration field includes a base identifier followed by a reserve bit (r1). The control field consists of an identifier extension (IDE) bit, an extended data length (EDL) bit, a reserve bit (r0), a bit rate switch (BRS) bit, an error state indicator (ESI) flag and a data length code (DLC). The EDL bit is also referred to as the Flexible Data Format (FDF) bit. The CRC field includes a CRC sequence and a CRC delimiter. The ACK field comprises an ACK slot and ACK delimiter.
The CAN FD extended format includes an arbitration field which consists of the base identifier, a substitute remote request (SRS) bit, the IDE bit, the identifier extension, and reserve bit (r1) and a control field which consists of the EDL bit (which may be referred to as the FDF bit), reserve bit (r0), the BRS bit, the ESI flag and the DLC.
All CAN FD frames formats include a CRC field comprising a CRC sequence and CRC delimiter. However, the length of the CRC sequence differs for different frame formats, namely 15 bits for CAN base and CAN extended frame formats, 17 bits for CAN FD frames which contain up to 16 bytes and 21 bits for CAN FD frames which contain more than 16 bytes.
The BRS bit marks a transition from the arbitration phase to the data phase. The CRC delimiter in a CAN FD frame signals a transition back to the arbitration phase.
Although the CAN FD protocol is based on part B of the CAN protocol (herein referred to simply as “CAN 2.0B”), it has limited backward compatibility with the CAN 2.0B protocol. A CAN FD node is able to receive and transmit CAN messages according to ISO 11898-1. However, a CAN node which can send and receive messages according to CAN 2.0B protocol (herein referred to as a “CAN 2.0B node”) cannot identify CAN FD messages and so, on receipt of a CAN FD message, will respond with a CAN error message.
This can hinder implementation of a CAN system comprising a mixture of nodes which comply with CAN 2.0B but not CAN FD and nodes which comply with CAN FD.
One solution is to use partial networking whereby nodes can be selectively powered down, placed in sleep mode or kept in standby. However, this still means that CAN 2.0B and CAN FD nodes cannot directly communicate.